feat(core): add configured model variant fallbacks - #43574

AI code review — automated review for reference; please use your judgment.

1. packages/core/src/plugin/variant.ts:47 — suppress is a silent behavior change: previously an explicitly-configured variant list was merged with generated variants (explicit ids overriding), now any non-empty variants array disables generation entirely — users who configured one custom variant will lose the auto-generated low/medium/high set after upgrade — call this out prominently in the changelog/release notes, and consider whether keeping generated siblings would be less surprising.

2. packages/core/src/plugin/variant.ts:120 — OPENAI_EFFORTS hard-guesses future effort names (none, xhigh, max) for unknown models; if a provider doesn't accept one of them, the failure surfaces as a request-time 400 rather than at configuration time, and every fallback variant for that model is affected — consider filtering against declared model capabilities/reasoning support when available, or at least documenting that variants: [] is the escape hatch.

3. packages/core/src/plugin/variant.ts:16 — loaded.entries is read once before the config.updated subscription is established — a config change landing between the initial entries() fetch and Stream.subscribe is silently missed until the next update — subscribe first (or re-read entries once after subscribing) to close the startup race.

4. packages/core/src/plugin/variant.ts:225 — claudeModel()/googleVariants() version heuristics encode vendor naming conventions in regexes (gemini-2[.-]5, major < 4 || minor <= 5 boundaries); they're well tested today, but each future Claude/Gemini generation needs a code edit here — consider sourcing these thresholds from model metadata/limits instead of literals when the catalog exposes them.

5. Nit — packages/core/src/plugin/variant.ts:96 — configuredModels treats any document entry mentioning a provider/model as "fallback" even if that entry only sets cosmetic fields (e.g. name) — that's the intended semantic per the tests, but the key set is built across ALL layers while only the last variants field wins; a brief comment explaining the layering rule would help future readers.

Overall: strong feature — the intent ladder (clear/suppress/fallback), the layered-config test, and the exhaustive package-matrix unit tests give good confidence in the core scenarios. Item 1 is the main thing to communicate; item 3 is a tiny race worth closing. Thanks!